Path: tosspot!indep1!pete From: pete@indep1.UUCP (Peter Franks) Newsgroups: to.tosspot Subject: TCP Digest #136 Message-ID: <1337@indep1.UUCP> Date: 14 Sep 90 01:27:13 GMT Reply-To: pete@indep1.MCS.COM (Peter Franks) Followup-To: to.tosspot Distribution: to Organization: as little as possible Lines: 191 TCP-Group Digest Wed, 12 Sep 90 Volume 90 : Issue 136 Today's Topics: Ethernet mysteriously quit working (2 msgs) Mailbox ID multispeed fdx repeater? (2 msgs) SSIDs and NETROM IDs why the H in [NET-H$] Send Replies or notes for publication to: Send requests of an administrative nature (addition to, deletion from the distribution list, et al) to: Archives of past issues of the TCP-Group Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives". ---------------------------------------------------------------------- Date: Tue, 11 Sep 90 14:28:51 CDT From: Jay Maynard Subject: Ethernet mysteriously quit working To: tcp-group@ucsd.edu Gerry, N5JXS' NOS quit working on his office Ethernet a couple of days ago. Over the weekend, the routers connecting his network to the outsied world were powered off and back on, and possibly reconfigured. Unfortunately, he can't do anything on his local LAN either. He's running an NE1000 and the Clarkson V7 packet driver, and NOS 900828. He sees traffic on the lan (as verified by a 'trace et0 0x111' command), but never transmits. Any ideas? ------------------------------ Date: Wed, 12 Sep 90 04:14:38 UTC From: karn@ka9q.bellcore.com (Phil Karn) Subject: Ethernet mysteriously quit working To: jmaynard@thesis1.hsch.utexas.edu, tcp-group@ucsd.edu Jay, When NOS stops transmitting, one of the first things to check is buffer memory exhaustion (either caused by a memory leak bug or by simply not having enough memory). Do a "mem stat" and see if the failure counts are increasing. Of course, rebooting the system should get it working again. If this DOESN'T do it, then something else is wrong -- perhaps his network's IP addresses were changed? Phil ------------------------------ Date: Tue, 11 Sep 90 09:37:09 EDT From: crompton@NADC.NADC.NAVY.MIL (D. Crompton) Subject: Mailbox ID To: rutgers!wb3ffv.ampr.org!howardl@ucsd.edu, tcp-group@ucsd.edu The 'H' in [NET-H$] stands for hiarchical (sp) forwarding. This tells the mailer the capabilities of the distant bbs. IF it is not there the sending bbs assumes the receiving bbs does not have this capability. Since TCP does have this capability it should be there. Doug ------------------------------ Date: Tue, 11 Sep 90 08:44:14 -0700 From: brian (Brian Kantor) Subject: multispeed fdx repeater? To: tcp-group I've put together a full-duplex two meter packet repeater that regenerates the FSK tones by the simple expedient of hooking a TNC's demodulator to its modulator. That works really well for 1200 bps but for all practical purposes, is limited to that speed. I'd like to encourage the growth of other speeds, primarily 9600 bps, and I think having the repeater capable of that speed would be a boost. I don't want to put up a repeater that is 9600 bps only, because it would receive little use and simplex 1200 bps would probably continue to occupy its input and outputs. I've come up with two schemes for multi-speeding the repeater: 1) have another modulator/demodulator hooked in, such as a hacked K9NG or G3RUH modem, and OR the 1200 and 9600 bps DCDs into PTT, and use each one to gate the audio from the respective modulator into the transmitter. 2) simply make the audio passband between receiver and transmitter flat and linear over 30Hz to 15kHz or thereabouts, so that it would be able to repeat either the AFSK 1200 bps stuff OR the direct-FSK output from the K9NG modems. I'm not sure what I'd do to key the transmitter - a simple noise squelch is out because I don't want people talking through the thing. I can do either, I think. The receiver is that wide, and the transmitter is a direct-FM widget, so it ought to be possible to do #2, which I'm leaning towards because it's cheaper. Suggestions? Anyone tried anything like this? - Brian ------------------------------ Date: Tue, 11 Sep 90 12:13:56 PDT From: Brian Lloyd Subject: multispeed fdx repeater? To: tcp-group@ucsd.edu I built a packet repeater that had a very flat audio passband (you can't get flat out to 15 kHz without a lot of extra bandwidth in the receiver) and the transmitter was keyed by the DCD output of a real Bell 202T modem (it did not false on voice at all). The plan was to add an FSK demodulator to generate DCD for 9600 bps FSK and then OR the two carrier detect circuits to generate a key-down voltage but we didn't get it completed. The plan should work tho' and it should be fairly inexpensive. BTW, I don't think that you need a transmitter with an FM modulator. It seems to work just as well to have a PM modulator with the correct preemphasis. 73 de Brian, WB6RQN ------------------------------ Date: Tue, 11 Sep 90 8:49:10 MST From: dlf@phx.mcd.mot.com (Dave Fritsche) Subject: SSIDs and NETROM IDs To: tcp-group@ucsd.edu (tcp-group) >This is guaranteed to be unique for all AMPRNET hosts. The bit-twiddling >can be done by a simple C routine, and might even be built into the netrom >commands in NOS. I know there's been a similar scheme mentioned on >Compu$erve, but that one (using the hex representation of the low 16 bits) >would break down at the edges of the assignment areas. What we are all using here in Arizona and New Mexico, is something that sounds similar to the Compuserve method. Instead of just the lower 16 bits though, we convert the lower 24 bits to hex and just use that as the NETROM node ID. I don't see any good reason to include the "#" in the node ID. In fact, with some versions of "The Net", IDs that begin with a "#", don't get rebroadcast. Some people here were using IDs with the "#" and couldn't figure out why they had such a high quality at a node, but weren't being passed on to the next one. Once they simply dropped the "#", everything worked as expected. The string of HEX digits as an ID is certainly unique. You can then also "pick out" the TCP/IP nodes at a glance, instead of having to search for "IP" or "TCP" burried in the sea of alphabet soup. It also allows someone else that has spotted your ID on the air, to go ahead and add the IP address to their "domain" table, or hosts.net file. If some of the folk that like to go spelunking around thru NETROM routes comes upon your node, who knows, maybe they'll like what they see and get involved in TCP/IP :-). Certainly, once they hit a node with an ID like that, they'll know from then on what to expect if they connect. Dave Fritsche (wb8zxu) dlf@phx.mcd.mot.com ------------------------------ Date: Tue, 11 Sep 90 13:34:29 GMT From: toth!dave (David B. Toth) Subject: why the H in [NET-H$] To: tcp-group@ucsd.edu In response to Howard Leadmon's question, the H identifies that the receiving station is prepared to handle hierarchical addressing in the @BBS field ... it oddoes not have to guarantee that it understands them, but only that it will accept it without barfing and presumably pass it on ... ex SP W3IWI @ W3IWI.MD.USA would be passed if the H was there; otherwise only SP W3IWI @ W3IWI would be passed if the exchange was [NET-$] 73, Dave VE3GYQ ria.ccs.uwo.ca!toth!dave ------------------------------ End of TCP-Group Digest ****************************** -- +------------------------------------------------------------------------------+ | Peter Franks | pete@indep1.mcs.com OR pete@indep1.uucp | | NI9D | Use whichever one works | +------------------------------------------------------------------------------+